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PRE-APPEAL BRIEF REQUEST FOR REVIEW 

Claims 1, 3-5, 6, 8-9, 12, 13, 16, 18, 19, and 20-24 stand rejected under 35 U.S.C. § 
103(a) as being unpatentable over U.S. Patent No. 6,496,865 ("Sumsion") in view of U.S. 
Patent No. 6,947,965 ("Glass"). In maintaining the above rejection and issuing a final 
rejection, the Applicant asserts that the Examiner has failed to satisfy the requirements set 
forth in MPEP § 2143. Specifically, in order to establish a prima facie obviousness rejection, 
MPEP § 2143 requires that "the prior art reference (or references when combined) must teach 
or suggest all the claim limitations." 
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Turning to the claims, claim 1 recites: 

A computer implemented method for a system having distributed collaborating components, 
comprising: 

restricting direct interaction between a first distributed collaborating component and a second 
distributed collaborating component by introducing an application-independent 
interface between the first and second distributed collaborating components; 

invoking a service from the application-independent interface to enable interaction between 
the first and second distributed collaborating components; and 

sending a usage specification as an argument to the application-independent interface, 
wherein the usage specification comprises a server object and a plurality of attributes 
associated with the server object that are requested by the first distributed 
collaborating component from the second distributed collaborating component, 

wherein the application-independent interface is configured to: 

interpret the usage specification to determine the plurality of attributes 

to fetch from the second distributed collaborating component; 
obtain the plurality of attributes from the second distributed 

collaborating component; and 
provide the first distributed collaborating component with the plurality 
of attributes. [Emphasis Added] 

Independent claim 1 explicitly requires (i) sending a usage specification as an 
argument to the application-independent interface; and (ii) interpreting the usage 
specification to determine the plurality of attributes to fetch from the second distributed 
collaborating component. Moreover, the claims clearly recite that the usage specification 
includes "a server object and a plurality of attributes associated with the server object..." 
Said another way, the usage specification is a specification , which at a minimum, specifies a 
server object (as opposed to being an object itself) and specific attributes of the server object 
that need to be fetched (as opposed to fetching the entire object). 

The Examiner has admitted that Sumsion does not teach sending a usage specification 
as an argument or that the usage specification comprises a server object and a plurality of 
attributes associated with the server object {See Office Action mailed February 16, 2006, 
page 3). However, the Examiner has asserted that Glass teaches the usage specification as 
recited in the pending claims. Glass teaches a system that allows communication between 
compatible and non-compatible object request brokers (ORBs). {See Glass, col. 3, 11. 66 - 
col. 4, 11. 2). ORBs are specifically related to providing a method for messaging between 
objects in Common Object Request Broker Architecture (CORBA). However, the teachings 
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of Glass are not equivalent to the usage specification as recited in independent claim 1. 
Specifically, Glass does not teach or suggest any file {i.e., usage specification), sent as an 
argument to the application-independent interface, where the specification identifies a server 
object and a plurality of attributes associated with the server object that are to be fetched from 
a second distributed collaborating component to be provided to a first distributed 
collaborating component. Further, Glass fails to teach interpreting a usage specification to 
determine the plurality of attributes of a server object that are to be fetched (based on usage) 
from the second distributed collaborating component. 

Specifically, the Examiner asserts that Glass teaches sending a usage specification, as 
an argument, to the application-independent interface. Applicant respectfully disagrees. 
Glass discloses "The method of remote proxy 154 invoked by client application 108 packages 
the arguments for the requested method and passes them to reference object 158..." {See 
Glass, col. 13, 11. 42-45). The arguments disclosed in the cited portion of Glass refer to 
objects or variables (or variables as references to objects) that are sent as part of the 
requested method. Nothing in Glass discloses that any of these arguments are a usage 
specification, which is wholly different than an object or a variable itself, as clearly recited in 
the claims and discussed above. The usage specification recited in the claims cannot be one 
of the arguments {i.e., objects, variables, or references to objects) taught in Glass because the 
usage specification specifies how these exact arguments taught in Glass are actually used. 
Bottom line, a specification that defines usage of objects cannot be the objects (or references 
to the objects) themselves. Accordingly, to read the usage specification as equivalent to an 
object or variable effectively reads out an explicit limitation of the claim— this is improper. 

Further, the Examiner asserts that Glass discloses "interpreting a usage specification 
to determine a server object and a plurality of attributes to fetch from the second distributed 
collaborating component." The Applicant respectfully asserts that the interpretation of Glass 
asserted by the Examiner with respect to this claim limitation is overly broad and has 
effectively removed explicitly stated limitations within the claims. 

In particular, the Examiner has construed that teachings in Glass directed to encoding 
and decoding of messages between the client-side ORB and the server-side ORB {see Office 
Action mailed February 16, 2006, page 4) to be equivalent to the limitation "interpreting the 
usage specification to determine the plurality of attributes to fetch from the second distributed 
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collaborating component." However, the encoding/decoding of the arguments is completely 
unrelated to the interpreting of a usage specification because the arguments of the requested 
method are only encoded and decoded to correspond to the communication protocol of each 
of the ORBs (See Glass, col 13, 11. 45-54). Encoding and decoding are simply 
transformations of the arguments themselves for security/communication purposes and does 
not involve any interpretation of a description (i.e., specification) of usage to make a 
determination of what server object (and attributes) to fetch from another distributed 
collaborating component. Because Glass (as discussed above) fails to disclose that any of the 
arguments are usage specifications, it logically flows that it would never be necessary to 
interpret the arguments disclosed in Glass. In fact, the arguments passed in Glass are simply 
variables, objects, or references to the objects and are not in the form of a specification about 
how the variable or object is used, so no interpretation of the argument itself is required. 
Thus, it is clear from the disclosure in Glass that the arguments are not interpreted in any way 
to determine specific attributes of a server object to fetch from a distributed collaborating 
component. Reading Glass so broadly as to teach that such interpretation is taught would be 
improper and results in a nonsensical result. 

Finally, independent claims 1 clearly recites that the usage specification is interpreted 
to determine the plurality of attributes of a server object that need to be fetched from a second 
distributed collaborating component. Said another way, the entire server object including all 
its attributes is not fetched in the present invention. Rather, the usage specification allows a 
user to specify only the necessary attributes of a server object that need to be fetched. In 
contrast, Glass fails to disclose or suggest providing specified attributes of a server object to 
the client application. Rather, Glass specifically discloses that the result of the processed 
method is provided to the client application. The result disclosed in Glass contains the entire 
result of the processed method, and does not contain only the attributes specified by a usage 
specification. 

In view of the above, the Examiner has failed to show that all of the claim limitations 
of independent claim 1 are taught by Sumsion and Glass. Thus, the Examiner failed to satisfy 
the requirements set forth in MPEP § 2143. Independent claims 4, 6, 16, 22, and 24 include 
essentially the same limitations as independent claim 1 . Thus, the Examiner failed to satisfy 
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the requirements set forth in MPEP § 2143 with respect to independent claims 4, 6, 16, 22, 
and 24 for at least the same reasons as independent claim 1 . 

Claims 10 and 11 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Sumsion and Glass in view of Admitted Prior Art ("APA"). As discussed above, the 
Examiner failed to satisfy the requirements set forth in MPEP § 2143 with respect to 
independent claims 1, 4, 6, 16, 22, and 24. Each of claims 10 and 1 1 depend from one of the 
aforementioned independent claims. Thus, the Examiner has also failed to satisfy the 
requirements set forth in MPEP § 2143 with respect to 10 and 1 1 for at least the same reasons 
as discussed above with respect to independent claims 1, 4, 6, 16, 22, and 24. 



Conclusion 

In view of the above, the Examiner has failed to satisfy the requirements set out in 
MPEP §2143. Accordingly, a favorable decision from the panel is respectfully requested. 
Please apply any charges not covered, or any credits, to Deposit Account 50-0591 (Reference 
Number 16159/023001; P6425). 
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